Today increasing numbers of web servers are migrating to a more secure version of secure hypertext transport protocol commonly known as HTTPS. HTTPS uses secure socket layer (SSL) and transport layer security (TLS) to provide different levels of encryption as necessary for different levels of security. As encryption techniques are improved with HTTPS, it becomes increasingly difficult for network sensing devices like an Intrusion Protection System (IPS) or virus/malware scanning firewall to perform packet inspection to analyze network traffic and identify potential attacks. Sensors have been developed to be able to decrypt data in network packets in two ways. The first, is referred to as a Man-in-the-Middle (MITM) proxy. The second is referred to as the “known key” approach.
In some implementations network security platforms (NSPs), sometimes referred to as sensors, prefer to use the “known key” approach because it is more efficient for heavy loads (e.g., large amounts of network traffic and/or large amounts of clients). This is particularly true for web servers having the intent of protecting the web servers inside an enterprise network from untrusted clients on a public network (e.g., the Internet). Analysis of this kind of network data may be referred to as an IBSSL decryption feature on a network sensor or firewall (e.g., an NSP or other computer device at the edge of the protected network). In prior art systems, the decryption feature is based on principle of providing the known private key of the “to be protected web server” on the NSP/sensor as part of its network configuration. This single private key may be used to decrypt the encrypted traffic to/from the web server. Standards provided for SSL/TLS protection provide support for a suite of public key cryptographic algorithms to implement the security. However, today IBSSL is only known to support the RSA algorithm (RSA is named after its inventors Rivest-Shamir-Adleman), which is a widely deployed algorithm. Even though RSA is widely used, there have been weaknesses found in that algorithm. As a result even stronger ciphers with more frequently changing keys are being introduced.
In the past, an administrator provided the known private key, as mentioned above, as part of the configuration of the protecting device (e.g., NSP). As a result, the NSP or other device could perform its function until the key was changed on the web server, for example. Newly introduced techniques for protecting network traffic include changing the web server key more frequently and thus make it impractical for an administrator to change the key on the NSP type devices. Without a key, the NSP cannot inspect the contents of network packets (e.g., deep packet analysis) and its capabilities as far as protecting against malicious data are degraded. Disclosed techniques address this and other problems, in part, by providing several enhancements to allow NSPs and other network protection devices to continue to perform desirable analysis even when the web server encryption key is changed frequently (e.g., ephemeral keys used by newer cipher suites).